1. Field of the Invention
The present invention broadly relates to data management systems, and more particulary, to a system and method for electronically changing configuration data for a software application.
2. Description of the Related Art
Millions of telephone calls are routinely placed in a telephone service provider's network. Telephone communication has seen a phenomenal growth since its inception because of its extreme usefulness in today's world. Traditional wireline telephone networks (e.g., the PSTN (Public Switched Telephone Network) or POTS (Plain Old Telephone System)) as well as the more recent wireless telephone networks (e.g., cellular wireless networks) have played a significant role in increasing the telephone traffic carried by a telephone service provider. It is hard, and almost impossible, to conceive a world without telephones. Telephones seem to have become an integral part of a civilized society.
In addition to oral communication, telephone connections are also made for data transfer activities, e.g., to transmit a fax or to send an electronic data file to another computer. The daily, widespread use of telephones requires a telephone service provider to maintain a log of its telephone line usage and devise appropriate telephone usage billing mechanisms. Billing or accounting errors may occur when telephone calls are improperly billed, for example, when charges appear on a subscriber's telephone bill for telephone calls that were abruptly terminated without any fault of the subscriber or for telephone calls that were charged at a rate different from the one the subscriber initially signed up for. A telephone service provider (TSP), thus, has to devise schemes to monitor and redress customer grievances for faulty billing.
As part of a streamlined billing and accounting procedure, the TSP may set up a central location or facility that houses service personnel authorized to access customer account data (e.g., for account maintenance or status inquiry) for all the customers in the service provider's network. Such a central processing facility collects the subscriber data from various regional offices and processes them according to the TSP's policy and guidelines. For example, a TSP may provide telephone services in Alabama, Kentucky, Tennessee and Atlanta, Ga. The TSP may have regional offices or regional service centers at these locations. In addition to these regional service centers, the TSP may set up a central processing facility at Atlanta, Ga. Therefore, the subscriber data (including, for example, the call records, the account information, the billing data, etc.) from all other regional service centers may have to be sent to the central processing facility for coordination of billing as well as account management.
Furthermore, the central processing facility may be at a location that is physically different from the location of the TSP's regional service center in Atlanta. In other words, the central facility may be in a building different from that for the TSP's regional service center. It is therefore desirable to achieve efficient data transfer between these two locations as well as between the central processing facility and other remote regional centers in view of the enormous data (including call records and billing data) generated within the TSP's network.
As used hereinbelow, a “message” or “call record” is generated and recorded as part of a telephone service provider's billing system each time a communication takes place between two parties through a call that was placed using the telephone service provider's network. Such messages typically appear on a telephone bill sent to the telephone subscriber. The term “error message”, as used hereinbelow, refers to a message that falls out of the regular billing stream due to a variety of reasons, for example, when a telephone subscriber complains about an erroneous entry or message on the subscriber's telephone bill and the telephone service provider's customer service person takes the message off the subscriber's bill and/or places the message under further investigation by appropriate service personnel. An error message may be generated when conflicting provisions in customer billing guidelines prevent the billing computer system from meaningfully keeping the message in the regular billing stream.
The term “case” is used hereinbelow to refer to a group of error messages that may be grouped together because of a common characteristic or a commonly identifiable error pattern. For example, when a new residential customer subscribes for a phone connection, the telephone service provider may inform the new customer that the customer's telephone line will start “working” (i.e., the customer will be able to receive a dial tone over the telephone line) from a specific date and/or time. This customer account activation information may then reside in a telephone service order (TSO) system in the service provider's mainframe computer for the regional office serving the customer. However, the telephone line in the new customer's residence may have been erroneously left activated by the service provider when the prior resident vacated that place. Thus, even though the telephone line is physically active, the billing system may not “recognize” it as being active until the activation date and/or time arrives. In other words, all telephone calls placed during this period of discrepancy may generate corresponding error messages with a common error pattern. These error messages may then be grouped as a case to facilitate quicker investigation thereof.
FIG. 1 illustrates a prior art scheme to transfer data from a mainframe computer system 25 in a TSP's regional service center to a central database 27 in a central processing facility. FIG. 1 further shows how error messages are handled by service personnel of the TSP. Billing data (including error messages) as well as customer account information and other data may reside in a regional mainframe computer system 25 in the TSP's network. The mainframe computer 25 may be physically located at a location remote from the central location (e.g., the central processing facility) where an authorized service person (ASP) or operator 29 of the TSP performs data processing, including processing of error messages. The ASP 29 may be located in a facility that houses other operators handling accounting/billing for the TSP.
Initially, the authorized service person 29 obtains printouts of data reports 30 generated by the mainframe system 25. These printouts 30 may contain text in ASCII (American Standards Code for Information Interchange) format. The printouts of data 30 may be sent to the ASP 29 via a third party hired by the TSP to maintain its customer accounts and coordinate the billing procedure. The ASP 29 thereafter begins manual data entry to transfer the data from the printouts 30 to the database 27 established in a local SQL server 32 (e.g., a Microsoft® SQL server) using a keyboard (not shown) or other data entry device for the workstation 34 operated by the ASP 29. The workstation 34 and the SQL server 32 form a client/server relationship for data transfer and database management operations. The steps involved in manual entry of data into the database 30 are discussed hereinbelow with reference to FIG. 2.
FIG. 2 outlines the steps involved when the operator 29 manually enters data from data printouts 30 into the database 27 using the workstation 34. The data entry process starts at step 36. At step 38, the operator 29 instructs the operating system (using the keyboard or another data entry device) running on the workstation 34 to execute an enterprise manager program residing in the workstation's 34 memory. Upon execution, the enterprise manager program establishes a link or connection between the workstation 34 and the SQL server 32 at step 40. In other words, data transfer can now be carried out between the workstation 34 and the SQL server 32. At step 42, the operator 29 opens the database 27 in the SQL server 32 remotely from the workstation 34 using the keyboard (not shown) or other data entry device for the workstation 34. Once the database is opened, the operator 29, at step 44, runs a query manager program residing in the workstation's 34 memory. Thereafter, the operator 29 executes an Insert Query command for each data entry on the printed reports 30 and manually enters the data from the printed reports 30 into the database 27. Once all the data on the printouts 30 are entered into the database 27, the ASP 29 closes the enterprise manager program at step 48. This signifies, at step 50, the completion of the manual data entry process.
Instead of storing the data into a central database, e.g., the database 27 in the SQL server 32, the ASP 29 may instead set-up or create a local database, e.g., a Microsoft Access® (MS Access) database, in the workstation's 34 memory. The manual data entry process for the MS Access database is essentially the same as depicted in FIG. 2, except that step 40 is absent in such a situation and the operator 29 opens the database in the workstation 34 instead of a server as in step 42.
The manual data entry process as outlined above is not only cumbersome and error-prone, but a quite inefficient utilization of manpower and computer resources given the ever-increasing demand for telephone services and, hence, correspondingly increasing amount of subscriber account and billing data. Employment of more service personnel to timely complete the data entry task is not a desirable solution given the enormous amount of data being generated by all the mainframe systems in the TSP's network. Further, manual data entry is error-prone given the monotonous and cumbersome nature of the data entry process. Human data operators may not perform at their best when the task is inherently tedious and boring.
It may therefore be desirable to devise a computer-based application that automatically and efficiently accomplishes transfer of large amounts of data from a number of mainframe systems to a central data base in a timely manner with minimal human involvement. It may further be desirable to simplify user access to the configuration parameters used by the computer-based application so as to enable the user to optimize the performance of the application in varying work conditions. Additionally, it is further desirable to substantially eliminate errors occurring during various data transfers so as to enable TSP service personnel to expedite further processing of available data.
As noted hereinbefore, FIG. 1 also illustrates how error messages are handled by service personnel of the TSP. The data reports or printouts 30 may include cases slated for review and investigation by the ASP 29. At the beginning of each case, a summary may be present informing the ASP 29 about the particular case. The summary may include a case-ID associated with the corresponding case. The case-ID may identify, e.g., symbolically or through a numerical code, the error or other salient characteristics common to the error messages contained in the corresponding case. For example, case-ID=60 may signify an invalid account status. The remaining text in the summary may succinctly mention other information, e.g., number of error messages contained in the given case, total amount in error, the name of the telephone carrier (e.g., a long-distance telephone company) that may be fully or partially responsible for the customer account being investigated, etc.
The ASP 29 manually inspects the printouts 30, one printout at a time, and manually identifies the errors from the case-IDs. Thereafter, the ASP 29 initiates error message processing by accessing, through the workstation 34, a CLUE (Correction of Local Usage Errors) system running on the mainframe computer 25. The mainframe computer system 25 is accessed so that the ASP 29 may actually enter appropriate processing notations for the error messages. The processing notation beside an error message may indicate whether the error message is deleted from the regular billing stream (i.e., the subscriber receiving credit for the error message), or whether the error message stays in the billing stream (i.e., the error message in fact does not contain an error and the subscriber is responsible for the amount charged), or whether the error message requires further investigation (e.g., by accessing other systems on the mainframe computer 25).
The CLUE system (not shown) is an application software running on the mainframe computer 25 that stores all error messages that are detected in the corresponding regional billing system of the TSP. The CLUE system includes a database of error messages for the region covered by the mainframe system 25 and functions separately from the regular billing system for that region. The ASP 29 or other operator may first initiate a network connection to the mainframe computer 25 via an emulator program (not shown) in the workstation 34. Once the network connection is established, the ASP 29 may “enter” the CLUE system and start manually keying-in (using the keyboard or other data entry device for the workstation 34) data for the error messages into the CLUE system. For each error message, the ASP 29 may also manually enter the corresponding processing notation (described hereinbefore) in the CLUE system. If no further investigation is needed for an error message, the ASP 29 may either rectify the error according to a predetermined set of instructions and send the corresponding error message to the regular billing system in the mainframe 25 or delete the error message from the CLUE system (and, hence, also from the regular billing stream).
However, in case of a further investigation, the ASP 29 may manually access (through the workstation 34) another system on the mainframe computer 25. For example, if an error message requires ascertaining a customer's telephone line configuration record or customer service record (CSR) (i.e., services selected by the customer on a given telephone line), the ASP 29 may access (through the workstation 34) a BOCRIS (Business Office Customer Records Information System) database (not shown) maintained on the mainframe system 25. On the other hand, if an error message necessitates looking at the customer's previous billing history or changes made to the BOCRIS database for a specific telephone line, then the ASP 29 may access the TSO (telecommunications service order) database (not shown) to retrieve the pertinent information. The ASP 29 may also need to access the GUIDE (Graphical User Interface Design Editor) system running on the mainframe computer 25 that keeps a table that instructs the billing system how to do billing for each phone number (e.g., whether to charge a promotional rate or whether to waive a monthly fee, etc.). Other applications running on the mainframe 25 may also be accessed depending on the error message and depending on the required investigation. Based on the information obtained from one or more of these systems, the ASP 29 manually either deletes the error message from the CLUE database or releases the error message for regular billing. In case of the need for still further investigation, the ASP 29 may place an appropriate notation against the error message in the CLUE system.
The foregoing describes a prior art method where investigators access the CLUE system to manually look up the cases and manually investigate and/or correct the error messages contained therein. A TSP operating in a number of states may face a daunting task of rectifying and/or investigating around 2-3 million cases (i.e., around 25-30 million error messages) per month in a timely fashion. The growth in the telephone industry and human population may generate with them additional subscriber base and, hence, additional telephone traffic. This further increases the already humongous case load each investigator has to manually handle in the TSP's central accounting facility. Manual correction of error messages seems to be a losing battle in view of ever increasing case data volume.
It is therefore desirable to devise a data management scheme to minimize involvement of human operators when a large volume of data is being handled. It is further desirable to substantially expedite correction of error messages with an automated arrangement to identify and rectify a large portion of error messages.